「ECサイト向け決済機能の開発で学んだ外部決済サービス活用のポイント」というテーマでLT登壇しました #Offers_決済サービス活用
2023.12.212023/12/05(火) Offers 主催「決済フロー全体像から学ぶ 決済サービス活用実践LT」に登壇しました。 その際の登壇内容を紹介します。
LT内容
資料
動画
Offers でアーカイブ動画を公開中です。
- 決済フロー全体像から学ぶ 決済サービス活用実践LT | Offers「オファーズ」 - エンジニア、PM、デザイナーの副業・転職採用サービス
- ※Offers の会員登録が必要となります。
LT目次
以下をポイントとしてお話しました。
- ECサイトでのクレジットカード利用
- 外部サービスとの通信タイムアウトの考慮
- 外部サービスを利用したテスト・リリースフロー
ECサイトでのクレジットカード利用
ECサイトでクレジットカード利用した決済の例
カード情報を扱う際のポイント
- カード情報の非通過・非保持
- カード番号などの情報は、利用者の画面と外部サービス間の通信のみ
- 情報漏洩などのセキュリティリスクが高くなるため、サーバーサイドにカード情報を通したり保存しない ことを推奨します
- カード番号などの情報は、利用者の画面と外部サービス間の通信のみ
- 外部決済サービスを採用する際は以下を確認
- PCIDSS(クレジットカードのセキュリティ基準)を遵守したサービスであること
- カード情報の非通過・非保持を実現できる機能があること
外部サービスとの通信タイムアウトの考慮
外部サービスからの予期せぬレスポンス
- 外部サービスからのレスポンスに時間がかかる場合が想定されます
- カード与信や返金に関わる処理は特に数秒かかることがよくあり、十数秒〜それ以上かかることも
- ECサイトのAPIクライアント側で設定した許容時間を超えると、クライアント側でタイムアウトとみなし通信が途中終了する可能性があります
外部サービスとの通信がタイムアウトする場合の例
最悪のケースとして
- システム上失敗とみなしているのに、実は外部サービス側の与信や売上が成功していることがありえます。
- 利用者が、「注文成立してないのに与信枠が使われたまま」という体験をしてしまうことも
通信タイムアウトに備えた対策
- 突合の仕組みを作る
- 不整合が生じていたら補填する
突合
ECサイトと外部サービスの状態を比較します。
不整合が生じていたら補填する
突合で不整合を検知した場合、以下のような補填を行います。
- クライアント側で注文成立していない ⇔ 外部決済サービス側では取引成立
- 外部決済サービスの取引をキャンセルする
突合・補填の対応を含めた例
決済代行サービスとの通信で予期せぬタイムアウトがあっても、突合以降の対応でステータスの整合性を担保できます。
外部サービスを利用したテスト・リリースフロー
- 「用意したテストがすべて成功しないとリリースが出来ない」仕組みは要注意です
- 「外部決済サービスのテスト環境起因でテスト失敗すること」を考慮しましょう
よくあるCI/CDフロー
外部サービス起因でテストが失敗すると…
- 外部サービスのテスト環境が不安定・またはサービス・メンテナンス等で停止しているとテストが失敗します
- テストが失敗するとビルド・リリースまで進まず、予定している機能提供が実施できないといったことがありえます
外部決済サービスの接続を伴うテストはリリースプロセスとは別で実行する
- 外部サービスに依存したテストが落ちた場合は以下を確認します
- 原因が 外部サービスの一時的な問題 であること
- プロダクトに起因したテスト失敗ではない こと
- プロダクトを直す必要がないことを明確にする前提で、ビルド・リリース可能とします
まとめ
- カード情報はサーバーに持たない、通さないこと
- 外部サービスの異常に考慮した設計・テストをすること
当日のQ&A
当日あったQ&Aで、私が回答した内容について抜粋します。
外部サービスのテストケースはどのくらい充実していますか？
主な正常系での疎通確認と、与信失敗などの異常系で自システムのロールバックが動作するかなどを確認しています。 リクエスト境界値や組み合わせなどの細かいパターンまでは網羅せず、「外部サービスとの通信」に特化したケースに絞ってテストを用意しています。
外部サービスを利用したテストが失敗するパターンとしてどのようなものがありますか？
外部サービスのテスト環境が商用環境に比べてスペックが低い場合が多く、一時的にリクエスト過多等で不安定になるケースがよく確認できます。 また、メンテナンス等で一時的に停止する場合もありえます。
外部サービスのテストでなぜ実際にリクエストを送っているのでしょうか？モックやスタブではカバーできないシナリオがあるのでしょうか？
「外部サービスとの通信が問題なくできていること」を担保したく、実際に外部サービスとも繋いだテストを実施しています。
最初の質問でも回答した通り、ケースは細かくパターン網羅せず一部の正常系・異常系のみに絞っています。また、開発の都度外部サービスとの通信も含めたテストを回すのではなく、日次などの頻度で動作確認をする形をとっています。
登壇を終えて
登壇内容についてリアルタイムで質問をいただき、特にテストに関わる質問が目立ったのは印象的でした。 外部サービスと実際に接続してテストすることは prismatix の開発内では当たり前のように行っていましたが、今回私が紹介した以外で皆さんどのような方法を取られているのかが気になっております。ぜひまた機会があればお話を伺ってみたいですね。
他の登壇者の話も非常に面白く、今後の開発の参考とさせていただきました。 同じように決済の悩みや壁にぶつかった話なども聞けて、改めて決済に関わるシステム開発の難しさを感じました。
私の今回のLT内容も、同じく決済システムに関わる方々の参考になれば幸いです。
